8장. 거리

출처: 『소프트웨어 설계의 결합 균형』(블라드 코노노프 지음, 장연호 옮김, 제이펍 2026) | 공식: https://www.jpub.kr/ 원서: Balancing Coupling in Software Design (Manning, 2024) | https://www.manning.com/books/balancing-coupling-in-software-design

지식이 흐르는 거리가 비용을 결정한다 — 같은 지식이 공유되더라도, 메서드 안에서 공유되는가 vs 다른 나라 서비스에서 공유되는가에 따라 변경 비용이 완전히 달라진다.

학습 목표

이 장을 끝내면 다음을 할 수 있다.

• 결합의 공간(space) 차원 — "거리"가 무엇이며 왜 중요한지 설명한다.
• 캡슐화 경계 5가지(메서드·클래스·네임스페이스·라이브러리·서비스)를 거리 순으로 배열한다.
• 거리가 변경 비용과 수명주기 결합 모두에 영향을 미치는 이유를 분석한다.
• 소유권 거리(사회기술적 요인)와 런타임 결합이 전체 거리에 어떻게 영향을 미치는지 설명한다.
• 거리와 통합 강도(7장)의 관계를 구분하고 두 차원이 모두 필요한 이유를 말한다.

전체 흐름도

[ 결합의 공간 차원 = "거리" ]
        |
        v
[ 캡슐화 경계 — 가까움에서 멀어짐 ]

  같은 메서드 안
      |
  같은 클래스 (객체)
      |
  같은 네임스페이스 / 패키지
      |
  같은 라이브러리 / 모듈
      |
  다른 서비스 (마이크로서비스)
      |
  다른 시스템 (조직 경계)

        |
        v
[ 거리가 커질수록 ]
    변경 비용 증가 + 수명주기 결합 감소

        |
        v
[ 거리에 추가로 영향을 주는 요인 ]
    1. 소유권 거리 (같은 팀 vs 다른 팀 vs 다른 조직)
    2. 런타임 결합 (동기 통신 vs 비동기 통신)

        |
        v
[ 거리 vs 통합 강도 — 두 차원이 모두 필요 ]
    거리만 늘린다 = "분산된 큰 진흙덩이" 위험
    지식 흐름(통합 강도)까지 함께 관리해야 진정한 모듈화

0. 사전 필수 용어

• 거리 (Distance) — 결합된 두 구성요소 사이의 물리적·사회적 공간. 가장 가까운 공통 조상 모듈로 측정한다.
• 캡슐화 경계 (Encapsulation Boundary) — 모듈이 외부에 드러내는 면과 숨기는 면의 구분선. 메서드·클래스·네임스페이스·라이브러리·서비스 등이 각각 하나의 경계.
• 수명주기 결합 (Lifecycle Coupling) — 두 모듈이 함께 구현·테스트·배포되어야 하는 정도. 거리와 반비례한다.
• 부수적 변경 (Collateral Change) — 수명주기가 결합돼 있어 직접 관련 없는 코드까지 함께 변경·배포해야 하는 현상.
• 소유권 거리 (Ownership Distance) — 결합된 모듈을 같은 사람·팀·부서·조직 중 누가 소유하는지에 따라 달라지는 인식된 거리.
• 런타임 결합 (Runtime Coupling) — 한 모듈의 가용성(availability)이 다른 모듈의 가용성에 영향을 미치는 정도. 동기 통신 시 높음, 비동기 통신 시 낮음.
• 통합 강도 (Integration Strength) — 모듈 경계를 넘나드는 지식의 양. 7장의 주제. 거리와 직교하는 다른 결합 차원.
• 근접성 (Proximity) — 거리의 반대 개념. 거리가 짧으면 근접성이 높다.

1. 거리란 무엇인가 — 공간 차원의 결합

5장~7장이 "얼마나 많은 지식을 공유하는가(통합 강도)"를 다뤘다면, 8장은 "그 지식이 얼마나 먼 거리에서 공유되는가"를 다룬다. 결합의 공간(space) 차원이다.

비유 — 같은 소문을 누구와 나누는가

비밀 하나가 있다고 하자. 이 비밀을 누군가와 나눠야 한다면:

• 옆자리 동료 — 나중에 생각이 바뀌면 돌아서서 "있잖아, 그 이야기 없었던 걸로 하자"고 바로 말할 수 있다. 수정 비용 거의 0.
• 다른 층 팀원 — 이메일 한 통, 짧은 미팅. 조정 비용 소폭 발생.
• 다른 회사 파트너 — 공식 채널, 계약 변경, 상대방 일정 조율. 비용이 훨씬 크다.
• 외국 펜팔 — 시차·언어·문화 차이. 같은 변경이라도 몇 주가 걸릴 수 있다.

소프트웨어도 동일하다. 같은 지식 공유라도, 이 공유가 같은 메서드 안에서 일어나는가, 같은 클래스인가, 다른 서비스인가에 따라 변경 비용이 완전히 달라진다.

코드로 — 같은 로직, 다른 거리 (그림 8.1)

아래 두 설계는 둘 다 "선호 고객(preferred customer) 판단"이라는 같은 지식을 두 곳에서 공유한다. 하지만 그 거리가 다르다.

A. 같은 객체의 두 메서드 — 거리 가까움 (잘못된 예: 중복이지만 변경 비용이 낮음)

# 잘못된 예: 같은 객체 안에 동일 로직 중복
class CustomerService:
    def method_a(self, customer):
        is_preferred = customer.spent_amount > 1000  # 로직 중복

    def method_b(self, customer):
        is_preferred = customer.spent_amount > 1000  # 동일 로직

선호 고객 기준이 바뀌면: CustomerService 하나만 수정·배포한다. 비용: 작음.

B. 두 마이크로서비스 — 거리 멈 (잘못된 예: 중복 + 변경 비용이 큼)

# 잘못된 예: 분산된 두 서비스에 동일 로직 중복

# 서비스 A (주문 서비스)
def is_preferred(customer):
    return customer.spent_amount > 1000

# 서비스 B (마케팅 서비스, 별도 코드베이스)
def is_preferred(customer):
    return customer.spent_amount > 1000  # 같은 로직, 다른 서비스

선호 고객 기준이 바뀌면: 두 서비스를 동시에 수정하고 동시에 배포해야 한다. 한 서비스만 배포하면 두 서비스의 판단이 달라져 시스템이 불일치 상태가 된다. 비용: 큼.

핵심 결론 — 결합된 구성요소를 변경하는 비용은 구성요소 사이의 거리에 비례한다.

2. 거리의 두 비용 — 변경 비용과 수명주기 결합

거리가 커질 때 발생하는 비용은 두 종류다.

2.1 변경 비용 (그림 8.2)

결합된 구성요소 간의 거리가 멀수록, 공유된 변경사항을 구현하는 데 필요한 조정 노력(coordination effort)이 커진다.

• 코드베이스 내 변경 조정 — 여러 파일·패키지에 걸친 수정
• 담당자 간 커뮤니케이션 — 같은 팀이면 구두, 다른 팀이면 미팅·티켓·이메일
• 인지 부하 증가 — 멀리 있는 모듈을 기억하고 동시에 업데이트해야 하는 부담
• 업데이트 누락 위험 — 거리가 멀수록 "아, 저쪽도 바꿔야 했는데" 실수 가능성 증가

2.2 수명주기 결합 (그림 8.3)

수명주기 결합은 거리와 반비례한다. 거리가 가까울수록(같은 객체, 같은 파일) 수명주기 결합이 강해지고, 거리가 멀수록(별도 서비스) 수명주기 결합이 약해진다.

비유 — 아파트 관리 vs 독립 주택

한 아파트에 사는 가족이라면, 계단을 고치는 공사가 있을 때 전 가구가 함께 영향을 받는다 — 같은 수명주기에 묶여 있다. 각자 독립 주택에 사는 이웃들이라면, 내 지붕 공사가 옆집에 영향을 주지 않는다. 독립 수명주기.

잘못된 예 — SupportCase 신(神)의 객체 (코드 8.1)

// 잘못된 예: 관련 없는 기능이 한 객체에 묶임 (SRP 최악 위반)
public class SupportCase {
    // 핵심 기능 (관련 있음)
    public void CreateCase(...) { ... }
    public void AssignAgent(...) { ... }
    public void ResolveCase(...) { ... }
    public void LogActivity(...) { ... }
    public void ScheduleFollowUp(...) { ... }

    // 관련 없는 기능들
    public void SendEmailNotification(...) { ... }  // 알림 로직
    public void SendSMSNotification(...) { ... }    // 알림 로직
    public void ProcessPayment(...) { ... }         // 결제 로직
    public double ConvertMilesToKilometers(...) { ... }  // 단위 변환
}

문제: 결제 로직을 배포하려면 SendEmailNotification의 미완성 변경사항도 함께 롤백하거나 브랜치로 분리해야 한다. 관련 없는 기능들이 같은 수명주기에 묶여 부수적 변경이 발생한다.

올바른 예 — 네 객체로 분리

// 올바른 예: 책임별 분리로 수명주기 독립
public class SupportCase { ... }       // 핵심 기능만
public class Notification { ... }      // 알림 로직만
public class Payment { ... }           // 결제 로직만
public class UnitConversion { ... }    // 단위 변환만

이제 결제 로직 배포가 알림 로직 배포와 독립된다. 관련 없는 기능끼리 수명주기가 분리됐다.

3. 거리 평가하기 — 공통 조상 모듈 (§8.1.3)

결합된 두 모듈의 거리는 가장 가까운 공통 조상 모듈로 측정한다.

비유 — 가족 관계도

두 사람이 얼마나 "가깝냐"를 따질 때 우리는 자연스럽게 공통 조상을 찾는다. 형제는 부모가 공통 조상. 사촌은 조부모가 공통 조상. 공통 조상이 멀수록 관계가 멀다.

소프트웨어 네임스페이스도 동일하다:

WolfDesk.Routing.Agents.Competencies.Evaluation   (타입 1)
WolfDesk.CaseManagement.SupportCase.Message        (타입 2)
WolfDesk.CaseManagement.SupportCase.Attachment     (타입 3)

• 타입 2와 3의 공통 조상: WolfDesk.CaseManagement.SupportCase — 가까움
• 타입 1과 2의 공통 조상: WolfDesk (루트) — 멈

따라서 타입 2-3 사이의 거리 < 타입 1-2 사이의 거리.

4. 거리에 영향을 주는 추가 요인 (§8.2)

코드 파일의 물리적 위치만이 거리를 결정하지 않는다. 두 가지 요인이 추가로 거리에 영향을 준다.

4.1 소유권 거리 — 사회기술적 요인 (§8.2.1)

비유 — 이웃 간 담장 공사

두 집이 공유하는 담장을 수리해야 한다고 하자.

• 같은 집 안 두 가족 구성원 — 저녁 식탁에서 합의. 내일 바로 시작.
• 옆집 이웃 — 시간 약속, 비용 분담 협의. 며칠 걸릴 수도.
• 다른 동네 땅주인 — 공식 문서, 법적 절차. 몇 주.
• 다른 나라 해외 법인 — 시차·법률·언어 장벽. 몇 달.

소프트웨어에서:

콘웨이의 법칙(Conway's Law, 1968): "시스템을 설계하는 모든 조직은 조직의 커뮤니케이션 구조를 복사한 구조를 가진 설계를 만들어낸다." — 즉, 시간이 지나면 소유권 거리가 캡슐화 경계에 영향을 미친다. 팀이 잘 나뉘면 시스템도 잘 나뉜다.

소유권 거리는 수명주기 결합도 줄인다: 다른 팀이 담당하는 두 마이크로서비스는 같은 개발·배포 일정을 공유할 가능성이 낮다 — 즉 수명주기가 더 독립적이다.

4.2 런타임 결합 (§8.2.2)

런타임 결합은 한 모듈의 가용성이 다른 모듈의 가용성에 영향을 미치는 정도다.

비유 — 전화 통화 vs 우편 메모

• 전화 통화(동기) — 상대방이 받아야만 통화가 성립. 상대가 자리를 비우면 나도 멈춘다. 강한 런타임 결합.
• 우편 메모(비동기) — 메모함에 넣어두면 상대가 언제든 읽으면 된다. 상대가 잠시 자리를 비워도 나는 계속 일한다. 약한 런타임 결합.

런타임 결합이 높으면 장애가 전파돼 두 서비스의 수명주기가 묶이고 인식된 거리가 줄어든다.

4.3 비동기 통신과 변경 비용 (§8.2.3)

비동기 통신이 런타임 결합과 수명주기 결합을 줄여주는 건 맞다. 하지만 통합 강도(지식 공유량)까지 줄여주지는 않는다.

두 서비스가 메시지로 내부 모델을 그대로 노출하면(모델 결합), 메시지 스키마가 바뀔 때 소비자가 두 버전을 모두 처리해야 하는 중간 버전이 필요해진다 — 동기 통신보다 오히려 더 복잡한 조정이 생길 수 있다.

이것이 이벤트 기반 아키텍처(EDA)가 자동으로 모듈화를 보장하지 않는 이유다. 레거시 시스템 중간에 메시지 버스를 끼워넣어도 지식 공유 방식이 최적화되지 않으면 "분산된 큰 진흙덩이(distributed big ball of mud)"가 될 뿐이다.

잘못된 예: 비동기지만 내부 모델 노출 (모델 결합)

{
  "customer_id": 42,
  "internal_credit_score": 750,
  "legacy_account_type_code": "P"
}

올바른 예: 의도(계약)만 노출

{
  "customer_id": 42,
  "is_preferred": true
}

5. 거리 vs 근접성 (§8.3)

"거리"와 "근접성"은 같은 동전의 양면이다. 저자가 "근접성" 대신 "거리"를 선호하는 이유:

• "거리가 높다/낮다"가 "근접성이 낮다/높다"보다 직관적으로 느껴진다.
• 변경 비용에 대한 거리의 직접적 영향이 생생하게 전달된다.
• 사회기술적 거리와 런타임 거리까지 포괄하는 표현이다.

6. 거리 vs 통합 강도 — 두 차원이 모두 필요한 이유 (§8.4)

공유 지식이 많을수록 연쇄 변경 가능성이 높아진다. 거리는 그 연쇄 변경을 구현하는 비용을 나타낸다.

흔한 함정 — 거리만 늘리기

모놀리스를 마이크로서비스로 쪼개는 것은 거리(캡슐화 경계)만 늘리는 접근이다. 하지만 지식 흐름(통합 강도)을 최적화하지 않으면 마이크로서비스들이 여전히 같은 이유로 함께 변해야 한다 — "분산된 큰 진흙덩이"가 된다.

따라서 10장(결합 균형)에서 두 차원을 하나의 통합 모델로 묶는다.

핵심 개념 정리

실무 체크리스트

• [ ] 같은 지식(로직)이 두 곳에 중복될 때, 두 곳 사이의 거리를 의식적으로 따졌나?
• [ ] 관련 없는 기능이 한 클래스/파일에 묶여 부수적 변경이 발생하는 곳이 있는가?
• [ ] 모놀리스를 마이크로서비스로 쪼갤 때, 통합 강도(지식 공유)도 함께 줄였나, 거리만 늘렸나?
• [ ] 두 서비스를 결합하는 팀이 같은 팀인가, 다른 팀인가? 소유권 거리를 고려했나?
• [ ] 동기 통신 vs 비동기 통신 선택 시, 런타임 결합 영향을 따졌나?
• [ ] 비동기 메시지가 내부 모델을 그대로 노출하는가, 의도(계약)만 노출하는가?
• [ ] 두 타입의 공통 조상 네임스페이스가 어디인지 인식하고 있는가?

연습문제 (문제만 — 정답은 부록 D)

1. 측정. 다음 세 타입의 쌍별 거리를 공통 조상 기준으로 비교하라. 어느 쌍이 가장 가깝고 어느 쌍이 가장 먼가? A: Shop.Inventory.Products.PriceCalculator B: Shop.Inventory.Warehouse.StockChecker C: Shop.Orders.Checkout.PaymentProcessor

2. 분석. SupportCase 클래스에 지원 사례 관련 메서드 5개와 ConvertMilesToKilometers() 메서드가 같이 있다. 이로 인해 생기는 수명주기 결합의 실제 문제를 시나리오로 서술하고, 해결 방법을 제안하라.

3. 판단. "마이크로서비스로 쪼개면 결합이 줄어드니 무조건 좋다"는 주장의 반례를 하나 드는 코드 예시 또는 시나리오를 작성하라.

4. 비동기. 주문 서비스(생산자)가 카프카로 OrderPlaced 이벤트를 발행하고 배송 서비스(소비자)가 이를 구독한다. 비동기 통신임에도 여전히 강한 결합이 남아 있는 경우를 두 가지 들고, 각각의 완화 방법을 말하라.

5. 콘웨이. 한 스타트업의 백엔드 팀이 세 명이 함께 하나의 Rails 모놀리스를 개발했다. 이후 결제·물류·사용자 세 팀으로 나뉘었다. 콘웨이의 법칙에 따르면 시스템 아키텍처가 시간이 지남에 따라 어떻게 변화할 가능성이 높은가?

최신 동향 (검증 2026-05-21)

• 모듈 모놀리스(Modular Monolith) 재조명 — 마이크로서비스가 거리를 극단적으로 늘린 결과 오히려 소유권 거리·런타임 결합 비용이 커지는 사례가 누적되면서, 거리는 줄이되 캡슐화 경계는 명확히 유지하는 모듈 모놀리스가 현실적 대안으로 주목받는다. Shopify Engineering Blog 등 실전 사례 다수.
• 팀 토폴로지(Team Topologies) + 콘웨이 역설계 — 콘웨이의 법칙을 역이용(Inverse Conway Maneuver)해 원하는 아키텍처에 맞게 팀 구조를 먼저 재편하는 접근이 표준 조언으로 자리잡음. 소유권 거리를 의도적으로 설계하는 패턴.

부록 A. 용어 사전

부록 B. 핵심 비교표

캡슐화 경계별 거리·비용·수명주기 결합

거리에 영향을 주는 요인 3가지

거리 vs 통합 강도 비교

부록 C. 추천 참고 자료 & 링크

Tier 1 공식·표준

책 다른 장 안내

부록 D. 연습문제 풀이

1. (A-B 거리 < C와 나머지 거리)
2. A와 B: 공통 조상 = Shop.Inventory — 상대적으로 가까움
3. A와 C: 공통 조상 = Shop (루트) — 멈
4. B와 C: 공통 조상 = Shop (루트) — 멈

따라서 A-B 쌍이 가장 가깝고, A-C·B-C 쌍이 가장 멀다.

1. (시나리오) 긴급 보안 패치로 CreateCase 로직을 고쳐 즉시 배포해야 한다. 그런데 ConvertMilesToKilometers에 절반쯤 작업된 미완성 리팩토링이 같은 파일에 있다. 선택지: ① 미완성 코드를 롤백해 충돌 제거 후 배포 — 롤백 비용 발생 ② 미완성 코드를 별도 브랜치로 분리 — 나중에 병합 충돌 위험. 해결: ConvertMilesToKilometers를 UnitConversion 클래스(또는 별도 파일)로 분리해 수명주기를 독립시킨다.

2. (반례) 주문 서비스와 결제 서비스를 별 마이크로서비스로 분리했지만, 결제 서비스가 주문 서비스 DB 스키마에 직접 의존하는 쿼리를 날린다. 거리(다른 서비스)는 늘었지만 통합 강도(지식 공유 = DB 스키마)는 그대로다. 주문 테이블 컬럼을 바꾸면 결제 서비스가 깨지는 콘텐츠 결합의 분산판. "분리했으니 느슨하다"는 착각.

3. (강한 결합 두 가지) ① 스키마 결합: OrderPlaced 이벤트에 주문 서비스의 내부 필드(order_source_system_code, legacy_price_flag 등)를 그대로 노출하면, 주문 서비스가 내부 필드를 바꿀 때 배송 서비스도 반드시 바꿔야 한다. 완화: 이벤트 스키마는 의도(계약)만 — OrderConfirmed { orderId, deliveryAddress } 같이 외부에 안정적인 최소 정보만. ② 이벤트 의미 결합: "이 토픽은 항상 주문 생성"이라 암묵 가정하다가 주문 서비스가 수정 이벤트도 같은 토픽으로 발행하면, 배송 서비스가 잘못 반응한다. 완화: 이벤트 타입 필드 명시(event_type: "OrderCreated")로 암묵 가정을 명시 계약으로 전환.

4. (콘웨이 예측) 세 팀이 결제·물류·사용자 역할로 나뉘면, 초기 모놀리스는 시간이 지나며 팀 경계를 따라 세 모듈(또는 서비스)로 자연스럽게 분화될 가능성이 높다. 각 팀이 자기 영역을 소유하고 다른 팀과의 인터페이스를 명시화하면서 API 경계가 강화된다. 반대로 팀 경계가 불명확하면 코드도 뒤섞이고 소유권 없는 영역이 생겨 유지보수 공백이 발생한다.